1. Field of the Invention
This invention relates to computer systems and, more particularly, to the control of the data to, from, and between input/output devices in a new input/output architecture for computer systems.
2. History of the Prior Art
The input/output device interfaces of existing computer systems are adapted to perform input operations in which data flows from an input/output device via the interface to either the central processing unit (for programmed input operations) or system memory (for DMA input operations), or output operations in which data flows from either the central processing unit (for programmed output operations) or system memory (for DMA output operations) via the interface to the input/output device. There is no need for routing information to direct the data flow since the start point (the central processing unit or a range of DMA addresses) is explicit and the end point is implicit since most device interfaces drive a single device with only one possible route.
Data flows only when and if a command requests it; there are no autonomous flows of data. The command provides a direction and names one single device as all the routing information necessary.
The advent of multimedia means that in addition to performing input and output operations, computers need to be able to perform operations in which data flows from one input/output device to another. For example, ideally when playing an audio compact disk (CD) on a computer, data should flow from the compact disk drive to the audio input/output device of the computer to be converted into sound. In practice, the compact disk drive converts the digital data to analog audio data; the analog audio data then flows via a special cable to be mixed with the analog output of the audio device of the computer downstream from the digital-to-analog converters. In fact, even if digital audio data were available from the compact disk drive, a conventional system would have to read it into memory and, as a separate operation, write the data from memory to the audio device. The digital data in flowing from one input/output device to another would travel over the system bus twice, once to memory and once from it. Thus, two complete bus operations rather than a single operation in which data travels between input/output devices would be required.
The advent of multimedia computers creates a need for a more powerful input/output architecture. In particular, it requires the ability to route data more flexibly including between input/output devices, the ability to control isochronous flows of data (make data flow at a particular continuous rate until commanded to stop), and the ability to interpose processing elements on flows of data (e.g., mix two streams of data together).
Operations in which data is transferred from one input/output device to another require complex routing information. For example, a system playing a Motion Picture Experts Group (MPEG) encoded movie from a compact disk might route the MPEG data from the compact disk via a SCSI bus to an MPEG decoder device, decode the MPEG data into a first stream of audio MPEG data and a second stream of video MPEG data. The first stream of decompressed MPEG audio data is sent to an audio mixer device where it is combined with other audio streams, and the stream of mixed audio data is routed via an audio digital-to-analog converter (DAC) to a pair of headphones. The second stream of decompressed MPEG video data is routed via a rendering engine into a specified region of a frame buffer where it is mixed with other graphics images. The video output of the frame buffer is routed via a DAC to a monitor.
In this example, there are one source device (the CD drive), two destination devices (the headphones and the monitor), and a number of intermediate processing devices (the MPEG decoder, the audio mixer, the rendering engine, the frame buffer, and the audio and video DACs). The source device has a single output and no inputs. Each destination device has a single input and no outputs. Each intermediate device has one or more inputs and one or more outputs.
Prior art computer systems provide an ad hoc set of connections among their resources. The special analog audio cable connecting the CD drive to the analog output of the audio device of the computer is one such ad hoc connection. An application wishing to route audio data from the CD drive to the audio output of the computer has to be aware of the existence of the special cable in this particular configuration and of the specific manipulations of the hardware needed to cause data to flow via the cable. There is no general device-independent way to enumerate the available sources, destinations, and intermediate processing elements, nor is there any general way to establish or remove connections between them.
This contrasts with practices in the audio industry which has long provided studios in which sources of audio data, modulating elements such as vibrato and tremolo units, mixers and limiters, and audio outputs are represented as individual modules which a human operator may connect in appropriate configurations using physical wires called patchcords.
It is desirable to provide computer application programs with the ability to identify the available sources, destinations, and intermediate processing devices available in a particular configuration and to allow application programs to route data among these resources as best fits their needs, subject to the constraints of the underlying hardware, in ways analogous to the physical patchcords of an audio studio.
Nor does the prior art provide general techniques by which multiple application programs may share a collection of sources, destinations, and intermediate processing elements. Each of a group of application programs running simultaneously using the collection of input/output elements wants to establish its own set of connections between these resources and to establish its own context on each of the resources. Context as used herein refers to the conditions such as register states, switch enables, and the like necessary for any resource to function correctly with the application program.
In conventional input/output systems, an application sharing access to an input/output resource needs to have context on that resource only while the application is actually accessing it. At other times, some other application may be using the resource and placing its own context on the resource. Input/output resources are serially reused by the group of application programs sharing them, providing each application with the illusion of exclusive access.
If a group of application programs share access to a pool of input/output resources that support autonomous isochronous data flows, the resources can, in general, no longer be serially reused. Consider an MPEG satellite television application and a videophone application running together on a single computer and sharing a pool of input/output resources. Initially, the MPEG broadcast is playing and the videophone is idle. The video frames of the broadcast are being rendered into a region of the framebuffer, and the audio samples are being routed to the speakers. A videophone call is received. The system reduces the volume of the satellite broadcast, decreases the size of the broadcast image, creates a window and starts rendering video frames from the videophone into it, connects the audio output of the videophone to the mixer, and increases its volume until it is easily audible.
In such a case, the two applications are truly sharing the audio output rather than serially reusing it. During each audio sample interval, the mixer receives a sample from the satellite and a sample from the videophone, multiplies them by their fader values, adds them together and normalizes the result to the desired overall volume.
It is desirable to allow each application to construct the set of input/output resources it requires, to specify appropriate connections between those resources, and to place appropriate context on them independently of what other applications are doing with the same set of resources. It is also desirable for the underlying system to manage the serial reuse and true sharing implied by the configurations constructed by the applications.